System and method for workforce requirements management

ABSTRACT

The present invention provides a workforce requirements management system and method that determines future demand for service related transactions or activity and optimizes the planning of workforce to meet the future demand. Initially, the workforce requirements management system reviews historical data regarding transaction volume and service activity to determine the future demand for such transactions or service activities. The historical data may come from a conventional enterprise resource planning application and/or include demographic data and/or economic indicators. The workforce requirements management system can optimize a forecast by isolating certain variance factors and refining the forecast accordingly. A forecast can also be optimized by estimating transaction times and correlating variance factors with estimated transactions times. Additionally, the workforce requirements management system can optimize the forecast based on the queuing model employed for the particular service. Finally, the workforce requirements management system can create a long term resource plan that identifies the most efficient balance of full time equivalent and part time equivalent staffing levels to meet the long term forecast need at the desired service level at the lowest overall labor cost. Specific outputs generated by the workforce requirements management system include a transaction forecast, a resource forecast, a resource plan, and a resource schedule.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of copending U.S. utility applicationhaving Ser. No. 10/832,509 filed on Apr. 27, 2004, all of which isentirely incorporated herein by reference.

BACKGROUND

1. Field of the Invention

The present invention generally relates to the planning of workforcerequirements and more particularly relates to a computer implementedsystem and method for determining future demand and the correspondingworkforce requirements to meet that demand.

2. Related Art

Rapid developments in computer resources have provided businesses in theservice industry with the potential to collect and maintain vasthistorical databases of transaction history. Conventional applicationscalled Enterprise Resource Planning (“ERP”) applications have beendeveloped over the years to generate such data. Examples of suchconventional ERP packages include SAP, Baan, PeopleSoft, and others.Accordingly, volumes of historical transaction data are available tothose businesses in the service industry that have archived the dataproduced by various ERP applications. For example, transaction datarelated to orders, service requests, and other activities is potentiallyavailable. Therefore, what is needed is a system and method that canaccess historical transaction data to predict what actions a serviceindustry business can take to address future transaction volumes.

SUMMARY

A computerized system and method to determine future demand for aservice or future transaction volume is presented. The level of futuredemand or transaction volume is used to determine the correspondingworkforce requirements needed to meet that future demand or transactionvolume. Future activity levels and corresponding workforce requirementneeds are provided that optimize the number of full time and part timeequivalents in the scheduled workforce.

The system capitalizes on the existence of previously created data fromconventional enterprise resource planning systems. The system mayadditionally use location dependent average activity times and externaldata from other systems related to transaction volume, demographicfactors, and economic indicators. The system uses all of this data toproduce a transaction volume forecast, a resource requirement forecast,a resource plan, and a resource schedule, which comprises arecommendation for the optimal workforce levels and mixes (part time,full time, etc.).

BRIEF DESCRIPTION OF THE DRAWINGS

The details of the present invention, both as to its structure andoperation, may be gleaned in part by study of the accompanying drawings,in which like reference numerals refer to like parts, and in which:

FIG. 1 is a block diagram illustrating an example system for workforcerequirements management according to an embodiment of the presentinvention;

FIG. 2 is a block diagram illustrating an example resource planningserver according to an embodiment of the present invention;

FIG. 3 is a flow diagram illustrating an example high level process forworkforce requirements management according to an embodiment of thepresent invention;

FIG. 4 is a flow diagram illustrating an example process for forecastingtransaction volume levels according to an embodiment of the presentinvention;

FIG. 5 is a flow diagram illustrating an example process for isolatingvariance factors to improve the accuracy of forecasting according to anembodiment of the present invention;

FIG. 6 is a flow diagram illustrating an example process for enhancingforecasts according to an embodiment of the present invention;

FIG. 7 is a flow diagram illustrating an example process for determiningtransaction and service activity times according to an embodiment of thepresent invention;

FIG. 8 is a flow diagram illustrating an example process for determiningthe necessary full time equivalent requirements to meet a predeterminedservice level according to an embodiment of the present invention;

FIG. 9 is a flow diagram illustrating an example process for optimizingstaff levels and work schedules according to an embodiment of thepresent invention; and

FIG. 10 is a block diagram illustrating an exemplary computer system asmay be used in connection with various embodiments described herein.

DETAILED DESCRIPTION

Certain embodiments as disclosed herein provide for systems and methodsto manage workforce requirements in a service industry organization. Forexample, one method as disclosed herein allows for historical datacreated by an enterprise resource planning (“ERP”) application to beanalyzed in order to forecast transaction volume or service activitylevels for a particular location. Certain demographic factors andeconomic indicators may also be employed to improve the accuracy of theforecast. Additionally, transaction times and service activity times canbe measured for the location in order to determine the full timeequivalent (“FTE”) requirements at a granular level (e.g., half hourlyFTE requirements). The FTE requirements can then be optimized with parttime equivalent (“PTE”) resources to identify the workforce (both FTEand PTE) requirements for the location and create a future workforceplan for the location.

After reading this description it will become apparent to one skilled inthe art how to implement the invention in various alternativeembodiments and alternative applications. However, although variousembodiments of the present invention will be described herein, it isunderstood that these embodiments are presented by way of example only,and not limitation. As such, this detailed description of variousalternative embodiments should not be construed to limit the scope orbreadth of the present invention as set forth in the appended claims.

FIG. 1 is a block diagram illustrating an example system 10 forworkforce requirements management according to an embodiment of thepresent invention. In the illustrated embodiment, the system 10comprises a resource planning server 20 configured with a data storagearea 30. The server 20 is communicatively coupled with a historical dataserver 40 over a network 60. The server 40 is also configured with adata storage area 50.

In one embodiment, the resource planning server 20 can be a stand-alonecomputer server, as will be understood by those having skill in the art.Preferably, the server 20 is connected to a network 60 so that is hasaccess to remote data storage areas such as database 50. Data storagearea 30 can be implemented as a conventional database with a databasemanagement system (“DBMS”) that controls access to the data storedtherein. Alternatively, the data storage area 30 can be a conventionalfile system or other implementation of a solution for the canonicalstorage of data.

Historical data server 40 may be implemented as a separate servercomputer or may be integrated on the computer as the resource planningserver 20. Similarly, data storage area 50 may be the same physicaldevice (or logical device with distributed physical devices) as datastorage area 30. Alternatively, data storage area 30 may be a discretephysical device. In one embodiment, data storage area 50 compriseshistorical data from an ERP server that can be accessed and analyzed bythe resource planning server 20.

The network 60 may be any type of network topology and employ one ormore network communication protocols, as will be understood by onehaving skill in the art. The function of the network 60 is to provideconnectivity and facility communication between the resource planningserver 20 and other server computers and data storage areas such ashistorical data server 40 and data storage area 50.

FIG. 2 is a block diagram illustrating an example resource planningserver 20 according to an embodiment of the present invention. In theillustrated embodiment, the resource planning server 20 is configuredwith a data storage area 30 and comprises a forecast module 100, avariance isolator module 110, a correlation module 120, a queuing module130, a resource optimization module 140, and a data acquisition module150. The data acquisition module 150 serves to obtain data from remotedata storage areas and convert such data to a format that is useable bythe appropriate module of the server 20.

The forecast module 100 is configured to analyze historical transactiondata and create a forecast of transaction volume for a particularlocation (or multiple locations, as necessary). The historicaltransaction data is preferably stored in the data storage area 30, butmay also be accessed by the forecast module via a network, for example,in combination with the data acquisition module 150.

The variance isolator module 110 is configured to analyze demographicand economic data and identify certain variance factors that may beapplied to a forecasted transaction volume to produce an enhancedforecast. In one embodiment, the forecast module 100 may preferablyemploy a forecast enhancement method that takes into account theidentified variance factors in order to produce an enhanced forecast oftransaction volumes for a particular location (or multiple locations, asnecessary). Advantageously, the variance factors identified by thevariance isolator may apply to a particular location or may be generallyapplicable to multiple locations or a geographic region (or some othercriterion) that describes a subset of locations.

The correlation module 120 is configured to analyze time studyobservations and location specific attributes, for example, attributesrelated to service activities. In this description, transactions andservice activities are used separately to describe separate concepts. Atransaction is a discrete event or set of events that can be welldefined, for example opening a new deposit account at a financialinstitution. A service activity is a completion oriented concept thatmay involve one or more events that mayor may not be repeated when theservice activity is performed by different employees in differentsituations at different times to serve different customers. For example,responding to a customer complaint may be described as a serviceactivity.

The correlation module 120 preferably analyzes time study observationsand location specific attributes that can be stored in a data storagearea or input by an operator and as a result of the analysis identifiesan average of transaction and service activity times on a pertransaction and per service basis per location.

The queuing model 130 is configured to analyze predefined target servicelevels, the correlated transaction and service activity times, and theenhanced transaction volume per location to create full time equivalentrequirements. In one embodiment, the FTE requirements identifies the FTErequirements for each position at a particular location.

The resource optimization module 140 is configured to analyze the FTErequirements in connection with data regarding service activities andhuman resource management objectives and requirements. The analysisconducted by the resource optimization module 140 preferably results inan optimized work schedule for a particular location that includes theuse of part time equivalent resources to more effectively andeconomically meet the forecasted need. Additionally, the analysis of theresource optimization module 140 preferably results in a long term workforce requirements that assist in the long term planning of full timeand part time equivalent resources and their corresponding skill sets.

FIG. 3 is a flow diagram illustrating an example high level process forworkforce requirements management according to, an embodiment of thepresent invention. Initially, in step 200, the transaction volume perlocation is forecasted. The transaction volume may also be forecasted ina more granular fashion such that the volume per transaction type pertime interval per location is forecasted. In order to create thisforecast, historical transaction data is preferably analyzed. In oneembodiment, a forecasting module can be tasked with creating transactionvolume forecast.

Next, in step 205, certain variance factors are identified. Theidentification of these factors can be the result of analyzingdemographic and economic data associated with historical transactioninformation. In one embodiment, a variance isolator module can be taskedwith identifying the variance factors. As will be understood by onehaving skill in the art, steps 200 and 205 are not necessarilysequential. These steps and the other steps described herein withrespect to the flow diagrams may be carried out in parallel or in randomorder. The only restriction of the operational order of the describedsteps is the input. Accordingly, where one step requires the input fromanother step, then a sequential order of those steps is implied.

Once the forecast transaction volume and variance factors areidentified, in step 210 an enhanced forecast (per location or pertransaction per location) can be created. The enhanced forecastpreferably optimizes the initial forecast based on the particularvariance factors identified and any correlating data related to currentdemographic and economic conditions.

In step 215, actual or average transaction times and service activitytimes are collected and identified. In one embodiment, transaction andservice times may be collected by manual observations at selectedlocations. Then the correlations between these transaction and servicetimes and the location specific characteristics are investigated bymeans of a multivariate regression analysis. The resulting regressionequation is evaluated to determine the location specific regressionformulas for each transaction or service type.

Once the transaction times, service activity times, and the enhancedforecast are available, they are analyzed in step 220 in combinationwith predetermined targeted service levels to determine the necessaryworkforce required to meet the targeted service level. For example, thenumber of full time equivalents per time interval per location areidentified that are required to meet the targeted service level. In oneembodiment, a queuing module may be employed to create the FTErequirements.

After the FTE requirements are identified, in step 225 the requirementsare analyzed along with service activity information, human resourcemanagement data, and a proposed work week schedule. Accordingly, the FTErequirements are optimized with part time resources according toavailability and skill sets. In one embodiment, a resource optimizationmodule may be used to carry out this function. Preferably, theoptimization step results in a workforce schedule for a location (ormultiple locations), as illustrated in step 230, and also a long termworkforce plan for full time an part time equivalents per location, asshown in step 235.

In an exemplary embodiment, the workforce requirements management systemuses historical transaction data and a decomposition based forecastingalgorithm to estimate the future time-series transaction volumes.Additionally, historical transaction data, demographic data, andeconomic indicators are used to identify the sources of variance intransaction volumes due to assorted factors (trend, seasonality, monthlypatterns, etc.) in the time-series data. Moreover, the transaction andservice activity times are determined by using observation data inconjunction with historical transaction data.

When determining the FTE requirements, the system uses the enhancedforecast of transaction volumes and the established transaction andservicing activity times. Also, when the FTE requirements are optimized,the system utilizes a linear programming model which uses the forecastedFTE requirements, human resource constraints, cost considerations todetermine the optimum number of resources required, the optimum fulltimeand part-time mix of those resources, and a suggested work weekschedule.

FIG. 4 is a flow diagram illustrating an example process for forecastingtransaction volume levels according to an embodiment of the presentinvention. The process begins at step 250, where the workforcerequirements management system calculates the total daily transactionvolume per transaction type. To calculate the total daily transactionvolume, historical transaction data per each time interval (hour,half-hour, etc.) is consulted and analyzed.

Next, in step 255 the percentage of the daily transaction volume forparticular time intervals is calculated. A variety of time intervals maybe used, for example, per 8 hours, per 4 hours, per hour, and per halfhour. Depending on the desired granularity, other time intervals mayalso be employed. In step 260, the total transaction volume (pertransaction per day) is summarized so that it may be plotted for eachday of the month, as illustrated in step 265. Summarizing thetransaction volume is important because in certain cases many years ofhistorical transaction data may be analyzed and therefore the resultingmass of raw data would be cumbersome to work with and in mostcircumstances impractical given the physical limitations of memory spaceand processor power on a typical resource planning server.

Once the daily transaction levels for the month have been plotted, instep 270 the system defines an appropriate function that represents theparticular daily plot for the transaction level. Multiple functions maybe defined, as necessary, to represent specific transaction levels fordifferent transaction types. After a function (or set of functions) hasbeen defined, the daily transaction volumes for the next month may becalculated, as shown in step 275. These calculations may be broken downby transaction type.

In step 280, the forecasted daily transaction volume is divided intotime intervals according to the previously determined percentage ofdaily transaction volume per time interval. This breakdown may alsopreferably apply to the various different transaction types, and thecalculations may advantageously be performed for more than one location.Thus, the result of the process for forecasting transaction volumelevels is preferably a daily forecast of transaction volume, per timeinterval, per transaction type, per location.

An example deployment of the above described process for forecastingtransaction volume levels begins initially with a data import ofhistorical transaction data. In this step, transactions (for eachtransaction type, for each location, and for each time interval) from anERP system or main transaction data storage area are imported to atemporary database for the historical data period. The granularityassociated with the data import is defined by the desired time interval(e.g., hourly, half-hourly, 15 min, etc.).

Next, for each (1) day of the week; (2) transaction type; and (3)location, the percentage of total daily transaction volume is calculatedfor each time interval. These percentages define intra-day fluctuations(between time intervals). Next, the total daily transaction volumes arecalculated for each transaction type and for each location. Since thepercent total daily transaction volume for each time interval is stored,this aggregation does not cause the loss of intra-day fluctuationpatterns.

Next, for each (1) day of the week; (2) transaction type; and (3)location, the total daily transaction levels are plotted for each day ofthe month. A function can then be defined to fit the data in the plot.This function can then be employed to determine the total transactionvolume forecast for the particular day. Finally, the percentage of totaldaily transaction volume per time interval is used to break down thetotal daily forecast into hourly or half-hourly volumes as determined bythe desired time interval.

FIG. 5 is a flow diagram illustrating an example process for isolatingvariance factors to improve the accuracy of forecasting according to anembodiment of the present invention. Initially, in step 300, theworkforce requirements management system identifies those factors thatsignificantly (or moderately, depending on the threshold sensitivitylevel) impact transaction volume. This determination is made based uponan analysis of demographic factors, economic indicators, and historicaltransaction data (or perhaps a summary or random sample of historicaltransaction volumes).

For example, in step 310, a random set of historical transaction data isanalyzed to determine if it is affected by certain trends or seasonalfluctuations in the data. If so, then the historical transaction datacan be normalized by removing seasonal fluctuations and removing othertrends, as shown in steps 315 and 320. Once the historical transactiondata has been normalized (if necessary) the forecasts produced in theforecasting modules are revised by the appropriate normalizingtechnique, such as time series regression, Box-Jenkins method, etc.

Next, in step 305 a regression analysis is performed on the storedsample of historical transaction volumes, taking into consideration alsothe identified factors that impact transaction volume. In step 330, theresults of the regression analysis are examined to determine if theidentified factors have a statistically significant impact on thechanges in the transaction volume. If a significant impact is not found,the process circles back to identify other factors that affect thetransaction volume and those factors are then analyzed using theregression analysis.

Once the potential variant factors are identified and the statisticallysignificant factors are selected, the appropriate regression equation isidentified in step 335 and the percentage of variance attributable toeach specific factor is determined, as shown in step 340. Accordingly,in step 345, the source of the variance factors are also identified.

An example deployment of the above described process for isolatingvariance factors to improve the accuracy of forecasting transactionvolume levels begins initially with a classification of the factors thatcause fluctuation in the transaction or service demand level into twogroups. The first group defines time related factors such as trend,seasonality, monthly effects, weekly effects, daily effects, hourlyeffects and holiday (before, during or after) effects. The second groupdefines demographic factors such as average income, education level,etc. and economic indicators such as GDP growth, interest rate,unemployment rate, etc.

Next, the factors that cause transaction levels to fluctuate aredetermined and the transaction volume level is represented as a functionof these factors. For example, a multiple linear regression approach canbe employed to represent the transaction volume level as a function ofthe identified factors, as will be understood by one having skill in theart and explained further below.

In the multiple-regression model, the total transaction level is thedependent variable and the various independent variables are defined torepresent each of the above identified factors. The regression analysisproduces a functional form (of all the factors that impact transactionvolumes) that represents the total transaction volume with the leastamount of possible error.

Moreover, in the regression analysis, a sample from the transactionvolume level data per time interval (ie. hourly, half-hourly, etc) isused. As can be understood, the full data set, comprising transactionvolumes per time interval spanning multiple years, would require anextremely large database, the use of which is untenable for real timecalculations.

Next, the percentage of decomposition for the transaction volume levelvariance in terms of covariance of transaction volume level and theidentified factors is calculated. Advantageously, each of the factorsidentified in the first step are represented in the calculation. Theresult of the calculation is the percentage of transaction volumevariation that is explained by each of the previously identifiedfactors. Accordingly, an adjustment can advantageously be made in theforecasting process to compensate for the variation introduced by theparticular factor. The corresponding adjustment for the factor is thenincorporated in the forecasting algorithm to enhance the quality (i.e.,accuracy) of the forecast.

FIG. 6 is a flow diagram illustrating an example process for enhancingforecasts according to an embodiment of the present invention. In theillustrated embodiment, the process begins in step 385 when theworkforce requirements management system determines if a particularfactor is significant. If the factor is determined not to besignificant, then the factor is discarded in step 400 and the systemchecks to see if there are more factors, as determined in step 405. Ifthere are no more factors, the process ends at step 410. If there areadditional factors, the process returns to step 385 where the nextfactor is examined to determine if it is significant.

If a factor is significant, then in step 390 new coefficients and anenhancement technique for the forecasting equations are determined.Using the new equations with the appropriate new coefficients, theforecast of transaction volume per time interval (and per location) areconsulted to create an enhanced forecast of the transaction volume forthe particular transaction type, time interval, and location, asillustrated in step 395. Once the enhanced forecast is created, thesystem checks to see if there are more factors. If there are, theprocess continues. If there are not, then the process ends.

An example deployment of the above described process for enhancingtransaction volume level forecasts begins initially with obtaining afactor (identified by isolation of variance) and the contribution of thefactor in the variability of the transaction volume. If the contributionof the particular factor is significant, e.g., it is higher than acertain threshold level; a specific action is taken in the forecastingalgorithm.

For example if trend is an important factor, then the forecasted valuesare corrected with the trend coefficient. As will be understood by onehaving skill in the art, there are conventional methods to calculate aparticular trend coefficient such as double exponential smoothing, timeseries regression, Box-Jenkins, etc. Accordingly, the trend factor inthe historical data is calculated first and then the forecasted valuesare adjusted with the identified significant factor.

The adjustment technique may depend on ‘the trend factor calculationmethod. For example, the trend factor is first extracted and then theforecasting algorithm is executed and finally the forecasted values arecorrected with the trend factor. If the seasonality is an importantfactor, the seasonality coefficients are calculated and the forecastednumbers are adjusted with these coefficients (for example, if the lengthof the season is 6 months, the seasonality factor coefficients can bethe percentage of total seasonal transaction level that happen in thefirst month, second month, etc.). In more interesting examples, if thedemographic factors or economic indicators are determined to be animportant factor, their impact can be assessed by using a regressionanalysis. These assessments are incorporated to the forecasts to adjustthe estimates generated by the initial algorithm.

FIG. 7 is a flow diagram illustrating an example process for determiningtransaction and service activity times according to an embodiment of thepresent invention. Initially, in step 420, those factors are identifiedthat significantly impact the transaction time at the location.Alternatively, factors that moderately impact transaction time may alsobe identified, depending on the desired sensitivity. To identify thefactors, the system analyzes transaction time observational data andattributes that may be manually collected or automatically generated.Next, in step 425, a multivariant regression analysis is performed onthe identified factors, taking also into consideration the rawtransaction time observations and attributes.

If the regression analysis shows statistically sound results, asdetermined in step 430, then a regression equation is identified in step435. If the regression analysis shows the current factors do not explainthe variation in the service times, then the process returns to thepreviously described identification step 420 and more factors areinvestigated. Once a regression equation has been identified thatimproves the forecast, in step 440 a standard time per transaction perlocation is calculated, taking also into consideration the rawtransaction time observations and attributes.

An example deployment of the above described process for determiningtransaction and service activity times begins initially with anassessment of the transaction and service activity times for eachtransaction and activity type and an assessment of the total amount oftime per day required for these activities. Preferably, a time studymethodology is employed to collect transaction times and a work samplingmethodology is employed to collect activity times. These methodologiescan be manually implemented or automated.

Importantly, in service-oriented organizations, the nature oftransactions and service activities can vary greatly in duration. Thus,the exact duration of each transaction or service activity is notpredictable. For example, in the banking industry the same transactiontype within a branch network may vary greatly in duration due to branchspecific factors such as customer demographics or physical branchequipment, (e.g., a deposit with cash back may take longer in a branchthat has a large number of customers that speak English as a secondlanguage as compared to a branch that has predominantly an Englishspeaking customer base.

Accordingly, a correlation of the variability in transaction and serviceactivity times depending upon the various environmental anddemographical factors can be employed to improve the quality of thetransaction time estimation.

Thus, the correlation model initially determines a sample set oflocations where the time studies and work sampling are conducted. (Thisdescription assumes a service organization with multiple locations).This step requires careful analysis. In order to reduce the bias in thesample, the locations are preferably randomly selected. In addition, thesample set preferably includes locations that reflect all the differentcharacteristics of the organization in terms of size, location,demographic characteristics, type of the major transactions, etc.Therefore, the list of available locations can preferably be dividedinto strata and then a sample set is randomly picked in each stratum.

Once the sample locations are determined, the analysts conduct on siteobservations. During observation, an analyst randomly selects a resourceand observes the transaction type or service activity being executed andthe duration of time. The analysts also record if there is any specialfactor that effected the time. For example, if the customer requiredadditional assistance pursuant to a particular demographic factor, e.g.,senior citizen or young student.

The number of observations required for each transaction or serviceactivity type is determined based upon the variability of the collectedtimes. Statistical confidence intervals are created to make theseanalyses. Once enough data from observations is collected, the averageand standard deviations of each transaction and service activity typeare calculated for each location. Understandably, the average durationof time for each transaction or servicing activity of the same type willvary for each location because of location specific factors (i.e., typeof technology used in the location, size, customer demographics, etc.)or the way the transaction or servicing activity is delivered (i.e.,drive-through window or walk-in service, or the use of cash dispensingmachines in banking).

Next, all of the characteristics for the particular location areidentified and another statistical analysis is conducted to determinethe statistically significant factors affecting the transaction andservice activity times. A correlation analysis is next executed todetermine if certain auto-correlations exist among the statisticallysignificant factors. If there is strong auto-correlation, then one ofthe highly correlated factors is selected for a regression analysis thatis conducted to define the transaction times in terms of variouslocation characteristics. The resulting regression formulation helps toaccurately estimate the transaction time for the rest of theorganization (i.e., at the locations that were not present in the sampleset).

FIG. 8 is a flow diagram illustrating an example process for determiningthe necessary full time equivalent requirements to meet a predeterminedservice level according to an embodiment of the present invention. Inthe illustrated embodiment, the process begins in step 450 where theservice rate per location is determined. This service rate is identifiedwith the variable x. The service rate is calculated by analyzingcollected data representing the standard time per transaction perlocation.

Next, in step 455 the average customer arrival rate per location pertime interval is determined, which is calculated by the intensity offorecasted transaction per time interval per location. This averagearrival rate is identified with the variable y. The minimum resourcelevel (identified with the variable c) is then identified, as shown instep 460, so that c satisfies the equation y/x. Next, in step 465 theservice level is calculated and in step 470 the target service level isobtained, for example as a predetermined value in a file or table.

If the service level is greater than the target service level, asdetermined in step 475, then the system creates number of resourcesaccordingly, as shown in step 485. If the service level does not meetthe predetermined target service level, then the number of resources isincreased by one and the service level is re-calculated. The targetedservice level may also be re-obtained, although it may stay the same sothat step may be skipped in the second and further iterations. In oneembodiment, however, the targeted service level may change with theminimum resource level.

Once the calculated service level meets or exceeds the target servicelevel, the full time equivalent requirements for the time interval arecalculated in step 485 as previously described. If there are more timeintervals to examine, as determined in step 490, the process returns tothe identification of the initial minimum resource level step 460. Ifthere are no more time intervals to examine, then in step 490 it isdetermined if there are more locations to examine. If there are, thenthe process returns to the identification of the initial minimumresource level step 460. If there are no more locations, the processcompletes, as illustrated in step 498.

An example deployment of the above described process for determining thenecessary full time equivalent requirements to meet a predeterminedservice level begins initially with identifying the average transactiontime (also referred as service times) for each transaction type and theforecasted number of transactions for each transaction type and for eachunit time interval (e.g., hourly or half-hourly). The presentlydescribed type of process will be understood by one having skill in theart as a queuing model.

Queuing models with certain assumptions are significantly easier todescribe and therefore such a model will be discussed. Alternativemodels, not employing assumptions, may also be employed and arecontemplated by the present invention. One of these assumptions is thatthe Markovian property applies to the transaction intensity and activitytimes. In other words, it is assumed that all the transaction times areexponentially distributed. Another assumption is that the Poissonproperty applies to the transaction intensity per time interval (alsoreferred as arrival pattern) for all the transaction types. Furthermore,for many different transactions with a Poisson arrival pattern, thearrival pattern of the total transactions is again Poisson with the meanequal to sum of the means of the individual transactions. It is alsoassumed that a different customer performs each transaction.

The transaction time for the different transactions is also assumed tobe an independent exponential distribution with different means. But theoverall transaction time distribution is the mixture of theseexponential distributions, which is defined as hyper-exponentialdistribution. The mean of the transaction times is equal to the weightedaverage of the means of individual service times with the weightscalculated according to arrival rate of transactions. Thus, assuming thetransaction intensities are Poisson and the transaction times areexponential and there are multiple servers, the queuing model for thissystem is M/M/c.

Furthermore, because the service level criterion depends on customerwaiting time, the waiting time needs to be quantified. The waiting timedistribution for an individual arrival is calculated by conditioning thewaiting time upon the number of customers in the system at the time thearrival occurs. The waiting time distribution is determined by using thePoisson Arrivals See Time Averages (“PASTA”) approach. The queuing modeltherefore tries to calculate the number of required servers c in orderto have the targeted percentage of customers wait less than thespecified amount of time calculated.

An example queuing model will now be described to illustrate its use inthe calculation of the number of required servers c. Alternative queuingmodels may also be employed, as will be understood by one having skillin the art. In the exemplary model, λ_(i) is the arrival rate ofcustomers for transaction i; μ_(i) is the service rate of transaction ifor a server; and c is the number of servers. Assuming that there are ndifferent types of transactions, then λ and μ are defined as following:

$\begin{matrix}{\lambda = {\lambda_{1} + \lambda_{2} + \ldots + \lambda_{n}}} \\{\mu = \frac{{\lambda_{1}\mu_{1}} + {\lambda_{2}\mu_{2}} + \ldots + {\lambda_{n}\mu_{n}}}{\lambda_{1} + \lambda_{2} + \ldots + \lambda_{n}}}\end{matrix}$

In order to have steady state probabilities, λ/cμ should be less than 1.The steady state probability distributions of the system can be easilyderived, as will be understood by one having skill in the art.

Also, in the exemplary queuing model, let P, be the probability thatthere will be i people in the system. These probabilities are calculatedwith the following expressions:

$P_{i} = \left( {{\sum\limits_{n = 0}^{c - 1}\frac{\lambda^{n}}{{n!}\mu^{n}}} + {\sum\limits_{n = c}^{\infty}\frac{\lambda^{n}}{c^{n - c}{n!}\mu^{n}}}} \right)^{- 1}$$P_{n} = \left\{ \begin{matrix}{\frac{\lambda^{n}}{{n!}\mu^{n}}P_{0}} & {{{for}\mspace{14mu} 1} \leq n \leq c} \\{\frac{\lambda^{n}}{c^{n - c}{n!}\mu^{n}}P_{0}} & {{{for}\mspace{14mu} c} \leq n}\end{matrix} \right.$

Let W represent the waiting time of the customer and P(W<=t) be theprobability of an incoming customer will wait less than t minutes. Ifthere are c servers and there are less than or equal to c−1 customers inthe system, then a new customer arrival will not wait (i.e. W=0). Theprobability of this case is given as follows:

${P\left( {W = 0} \right)} = {\sum\limits_{n = 0}^{c - 1}P_{n}}$

If there are c servers and there are more than or equal to c customersin the system, then a new customer will have to wait. (i.e. W>0). Theprobability of waiting being less than the targeted level depends on thenumber of existing customers in the system. We can write the followingexpression to represent this conditional probability:

P(W≦t|new arrival finds n customers in the system)=P(n−c+1 completionsin t)

To determine P(W<=t), the above probability for each possible n iscomputed and summed. The resulting aggregate probability is thenmathematically equivalent to

${P\left( {W \leq t} \right)} = {{P\left( {W = 0} \right)} + {\sum\limits_{n = c}^{\infty}{{P\left( {{W \leq t}{n\mspace{14mu} {customers}\mspace{14mu} {in}\mspace{14mu} {the}\mspace{14mu} {system}}} \right)}P_{n}}}}$$\mspace{79mu} {{P\left( {W \leq t} \right)} = {{\sum\limits_{n = 0}^{c - 1}P_{n}} + {\left( {1 - {\sum\limits_{n = 0}^{c - 1}P_{n}}} \right)\left( {1 - ^{{({{c\; \mu} - \lambda})}t}} \right)}}}$

Accordingly, the minimum number of servers required to satisfy theservice criterion of having a certain percentage of the customers waitless that the targeted level, e.g., 85%, is determined by the followingmethod: (a) start with the smallest c where (λ/cμ<1); (b) determineP(W<=t) for t (5 min.) and if it is less than the targeted probability(e.g. 85%) then (i) increase c by 1 and go to step (b), else go to step(c); (c) repeat step (b) until P(W<=t) is less than the targetedprobability (e.g. 85%); and (d) the minimum number of servers is c.

The forecasting algorithm generates transaction frequency forecasts forevery unit time interval (i.e., for each half-hour interval). Thus, theabove described queuing model determines the required number ofresources for every unit time interval. This calculated number ofservers is the minimum numbers that the service organization needs inorder to provide the targeted service level.

FIG. 9 is a flow diagram illustrating an example process for optimizingstaff levels and work schedules according to an embodiment of thepresent invention. The process begins at step 500 where a representativefull time equivalent profile is determined for a particular location (orfor each location if there are multiple). Data that is analyzed in thisstep in order to make the determination includes the FTE requirementsfor each time interval (and for each location, as appropriate). Next, instep 505, the system determines the resource requirement profile afterexamining the service activity level data and representative FTE profileinformation. As with the previous step, this may be performed formultiple locations, as necessary.

Once the resource requirement profile has been determined, in step 510the system then executes the FTE requirement optimization model (perlocation) in order to identify the number of required resources withdifferent shift templates, which is performed in step 515. Data that isutilized in the execution of the FTE requirement model in step 510includes the resource requirement profile and predetermined shifttemplates that are determined based upon human resource data.

The system next, in step 520, executes the planning optimization model(per location) to determine in step 525 the long term number of fulltime equivalents and part time equivalents needed to meet the forecastedtransaction and service activity levels according to the desired servicelevel. Data that is utilized in the execution of the planning model instep 520 includes the identified number of resources with differentshift templates, employee work schedule constraints (derived from humanresource data), and certain cost coefficients (also derived from humanresource data). Additionally, in step 530 ‘the system determines anappropriate and optimized FTE and PTE work schedule (per location) thatpresents the most efficient combination of FTE and PTE employees to meetthe forecast transaction and service activity levels at the desiredservice level with the appropriate employee skill sets and at theminimum salary level.

In general, an efficient service organization should be able to increasestaff to meet the customers peak time needs as well as reduce staff whentraffic is slow and minimize the costs of these staffing adjustments.This is not possible unless the organization has a complement ofresources that can work shorter shifts, which vary from day to day, weekto week. However, too many part time resources (i.e., short shift andflexible schedule employees) can lead to greater turnover, increasedrecruiting and training costs, and a lower average skill set peremployee. Therefore, service organizations have the challenge of findingthe right balance.

Thus, any service organization employs certain full time resources withlow schedule flexibility but high retention and high skill level andother part time resources with high flexibility but low retention andlow skill level. Accordingly, a service organization needs to be able tooptimize the long term balance of its full time and part time workforcewhile at the same time optimizing short term weekly and monthlyschedules.

An example deployment of the above described process for optimizingstaff levels and work schedules begins initially with calculating thenumber of resources required in each unit interval. This calculation isdescribed above as taking place in the queuing model. The number ofresources that are output by the queuing model correspond to FTErequirements. Accordingly, optimizing the number of FTE requirementswill determine the best full time and part time resource mix andschedule those resources to fit the intraday and intra-week fluctuationsidentified by the queuing model.

Thus, in the optimization process, the workforce requirements managementsystem employs an integer linear programming (“ILP”) model. In order tosegment the ILP models into solvable sizes, the problem is divided intotwo models. In the first model, the requirement model, the optimumnumber and type of the resource schedule templates are determined. Theseschedules are optimized to ensure that there are enough employeeresources to adequately (and efficiently) cover the FTE requirements ofthe organization for transaction volume and service activity levels. Inthe second model, the planning model, the number of resources of eachtype (e.g., full time, part time, etc.) and their weekly workingschedules are determined based on human resource management rules.

In one embodiment, the workforce requirements management system alsoprovides for storage of time sensitive attributes and correlation ofthose attributes with historical transaction volumes. For example,historical data is stored as a dynamic set of time series basedattributes that are correlated to the historical transaction volumesthat are used to generate future forecasts. These attributes can bestatic values that change over time or they can be functions of time.

A time series based attribute can be assigned to any application objectand incorporated into the forecasting model. An example of a time seriesbased attribute would be an economic factor such as interest rate.Because a specifically defined interest rate has only one value for agiven point in time, interest rate values can be stored as a series ofvalues over time. These values are included in the forecast model byrelating them to a historical transaction volume. The current interestrate along with the correlated historical transaction volume can then beused as a factor in predicting future transaction volumes.Advantageously, the dynamic attributes associated with each applicationobject provide the level of granularity needed for a highly accurateforecast. For instance if forecasting for home loans, time seriesattributes at the corporate level, branch level, and processing centerlevel can be related to the historical demand over time for each level.

Attributes can also be a function of time that produces a value based onthe date. Some examples would be day of week, day of month, week inmonth, before or after holiday, or even social security checkdistribution day. These values can then be related to the correspondinghistorical transaction volumes being used to generate future forecasts.Attributes can dynamically be created on any application object by theuser and included as a factor in the forecast model to impact theforecasted demand.

FIG. 10 is a block diagram illustrating an exemplary computer system 550that may be used in connection with the various embodiments describedherein. For example, the computer system 550 may be used in conjunctionwith a resource planning server or other historical data server or thelike. However, other computer systems and/or architectures may be used,as will be clear to those skilled in the art.

The computer system 550 preferably includes one or more processors, suchas processor 552. Additional processors may be provided, such as anauxiliary processor to manage input/output, an auxiliary processor toperform floating point mathematical operations, a special-purposemicroprocessor having an architecture suitable for fast execution ofsignal processing algorithms (e.g., digital signal processor), a slaveprocessor subordinate to the main processing system (e.g., back-endprocessor), an additional microprocessor or controller for dual ormultiple processor systems, or a coprocessor. Such auxiliary processorsmay be discrete processors or may be integrated with the processor 552.

The processor 552 is preferably connected to a communication bus 554.The communication bus 554 may include a data channel for facilitatinginformation transfer between storage and other peripheral components ofthe computer system 550. The communication bus 554 further may provide aset of signals used for communication with the processor 552, includinga data bus, address bus, and control bus (not shown). The communicationbus 554 may comprise any standard or non-standard bus architecture suchas, for example, bus architectures compliant with industry standardarchitecture (“ISA”), extended industry standard architecture (“EISA”),Micro Channel Architecture (“MCA”), peripheral component interconnect(“PCI”) local bus, or standards promulgated by the Institute ofElectrical and Electronics Engineers (“IEEE”) including IEEE 488general-purpose interface bus (“GPIB”), IEEE 696/S-100, and the like.

Computer system 550 preferably includes a main memory 556 and may alsoinclude a secondary memory 558. The main memory 556 provides storage ofinstructions and data for programs executing on the processor 552. Themain memory 556 is typically semiconductor-based memory such as dynamicrandom access memory (“DRAM”) and/or static random access memory(“SRAM”). Other semiconductor-based memory types include, for example,synchronous dynamic random access memory (“SDRAM”), Rambus dynamicrandom access memory (“RDRAM”), ferroelectric random access memory(“FRAM”), and the like, including read only memory (“ROM”).

The secondary memory 558 may optionally include a hard disk drive 560and/or a removable storage drive 562, for example a floppy disk drive, amagnetic tape drive, a compact disc (“CD”) drive, a digital versatiledisc (“DVD”) drive, etc. The removable storage drive 562 reads fromand/or writes to a removable storage medium 564 in a well-known manner.Removable storage medium 564 may be, for example, a floppy disk,magnetic tape, CD, DVD, etc.

The removable storage medium 564 is preferably a computer readablemedium having stored thereon computer executable code (i.e., software)and/or data. The computer software or data stored on the removablestorage medium 564 is read into the computer system 550 as electricalcommunication signals 578.

In alternative embodiments, secondary memory 558 may include othersimilar means for allowing computer programs or other data orinstructions to be loaded into the computer system 550. Such means mayinclude, for example, an external storage medium 572 and an interface570. Examples of external storage medium 572 may include an externalhard disk drive or an external optical drive, or and externalmagneto-optical drive.

Other examples of secondary memory 558 may include semiconductor-basedmemory such as programmable read-only memory (“PROM”), erasableprogrammable read-only memory (“EPROM”), electrically erasable read-onlymemory (“EEPROM”), or flash memory (block oriented memory similar toEEPROM). Also included are any other removable storage units 572 andinterfaces 570, which allow software and data to be transferred from theremovable storage unit 572 to the computer system 550.

Computer system 550 may also include a communication interface 574. Thecommunication interface 574 allows software and data to be transferredbetween computer system 550 and external devices (e.g. printers),networks, or information sources. For example, computer software orexecutable code may be transferred to computer system 550 from a networkserver via communication interface 574. Examples of communicationinterface 574 include a modem, a network interface card (“NIC”), acommunications port, a PCMCIA slot and card, an infrared interface, andan IEEE 1394 fire-wire, just to name a few.

Communication interface 574 preferably implements industry promulgatedprotocol standards, such as Ethernet IEEE 802 standards, Fiber Channel,digital subscriber line (“DSL”), asynchronous digital subscriber line(“ADSL”), frame relay, asynchronous transfer mode (“ATM”), integrateddigital services network (“ISDN”), personal communications services(“PCS”), transmission control protocol/Internet protocol (“TCP/IP”),serial line Internet protocol/point to point protocol (“SLIP/PPP”), andso on, but may also implement customized or non-standard interfaceprotocols as well.

Software and data transferred via communication interface 574 aregenerally in the form of electrical communication signals 578. Thesesignals 578 are preferably provided to communication interface 574 via acommunication channel 576. Communication channel 576 carries signals 578and can be implemented using a variety of communication means includingwire or cable, fiber optics, conventional phone line, cellular phonelink, radio frequency (RF) link, or infrared link, just to name a few.

Computer executable code (i.e., computer programs or software) is storedin the main memory 556 and/or the secondary memory 558. Computerprograms can also be received via communication interface 574 and storedin the main memory 556 and/or the secondary memory 558. Such computerprograms, when executed, enable the computer system 550 to perform thevarious functions of the present invention as previously described.

In this description, the term “computer readable medium” is used torefer to any media used to provide computer executable code (e.g.,software and computer programs) to the computer system 550. Examples ofthese media include main memory 556, secondary memory 558 (includinghard disk drive 560, removable storage medium 564, and external storagemedium 572), and any peripheral device communicatively coupled withcommunication interface 574 (including a network information server orother network device). These computer readable mediums are means forproviding executable code, programming instructions, and software to thecomputer system 550.

In an embodiment that is implemented using software, the software may bestored on a computer readable medium and loaded into computer system 550by way of removable storage drive 562, interface 570, or communicationinterface 574. In such an embodiment, the software is loaded into thecomputer system 550 in the form of electrical communication signals 578.The software, when executed by the processor 552, preferably causes theprocessor 552 to perform the inventive features and functions previouslydescribed herein.

Various embodiments may also be implemented primarily in hardware using,for example, components such as application specific integrated circuits(“ASICs”), or field programmable gate arrays (“FPGAs”). Implementationof a hardware state machine capable of performing the functionsdescribed herein will also be apparent to those skilled in the relevantart. Various embodiments may also be implemented using a combination ofboth hardware and software.

While the particular systems and methods herein shown and described indetail are fully capable of attaining the above described objects ofthis invention, it is to be understood that the description and drawingspresented herein represent a presently preferred embodiment of theinvention and are therefore representative of the subject matter whichis broadly contemplated by the present invention. It is furtherunderstood that the scope of the present invention fully encompassesother embodiments that may become obvious to those skilled in the artand that the scope of the present invention is accordingly limited bynothing other than the appended claims.

1. A method for managing workforce requirements of a service industry organization, the method comprising: analyzing historical transaction data to generate a transaction volume forecast; analyzing the historical transaction data to identify demographic variance factors; analyzing the demographic variance factors to identify at least one demographic variance factor having a statistically significant impact on transaction time; determining a transaction time based on the at least one demographic variance factor identified; and creating a full time equivalent requirement forecast based on the transaction volume forecast and the transaction time.
 2. The method of claim 1 wherein analyzing the historical transaction data to identify the demographic variance factors comprises comparing a fluctuation in the historical transaction data caused by each of the demographic variance factors.
 3. The method of claim 1 wherein analyzing the historical transaction data to generate the transaction volume forecast comprises generating the transaction volume forecast based on the historical transaction data and the demographic variance factors.
 4. The method of claim 1 wherein the transaction volume forecast comprises a transaction volume per transaction type per time interval per location forecast.
 5. The method of claim 4 further comprising: determining coefficients based on the at least one demographic variance factor; and generating an enhanced transaction volume forecast based on the coefficients and the transaction volume per transaction type per time interval per location forecast.
 6. The method of claim 1 further comprising: determining a service rate per location by analyzing a standard time per transaction per location; determining an average customer arrival rate per location per time interval; calculating a service level per location based on the service rate per location and the average customer arrival rate per location per time interval; and if the service level per location meets or exceeds a target service level, calculating full time equivalent requirements to meet the target service level.
 7. The method of claim 1 wherein determining the transaction time comprises calculating the transaction time using multivariate regression analysis.
 8. A system for managing workforce requirements of a service industry organization, the system comprising: a processor configured to analyze historical transaction data to generate a transaction volume forecast, analyze the historical transaction data to identify demographic variance factors, analyze the demographic variance factors to identify at least one demographic variance factor having a statistically significant impact on transaction time, determine a transaction time based on the at least one demographic variance factor identified, and create a full time equivalent requirement forecast based on the transaction volume forecast and the transaction time.
 9. The system of claim 8 wherein the processor, to analyze the historical transaction data to identify the demographic variance factors, compares a fluctuation in the historical transaction data caused by each of the demographic variance factors.
 10. The system of claim 8 wherein the processor, to analyze the historical transaction data to generate the transaction volume forecast, generates the transaction volume forecast based on the historical transaction data and the demographic variance factors.
 11. The system of claim 8 wherein the transaction volume forecast comprises a transaction volume per transaction type per time interval per location forecast.
 12. The system of claim 11 further comprising: the processor configured to determine coefficients based on the at least one demographic variance factor and generate an enhanced transaction volume forecast based on the coefficients and the transaction volume per transaction type per time interval per location forecast.
 13. The system of claim 8 further comprising: the processor configured to determine a service rate per location by analyzing a standard time per transaction per location, determine an average customer arrival rate per location per time interval, calculate a service level per location based on the service rate per location and the average customer arrival rate per location per time interval, and if the service level per location meets or exceeds a target service level, calculate full time equivalent requirements to meet the target service level.
 14. The system of claim 8 wherein the processor, to determine the transaction time, calculates the transaction time using multivariate regression analysis.
 15. A computer readable medium comprising executable instructions which, when executed by a processor, manage workforce requirements of a service industry organization by directing the processor to: analyze historical transaction data to generate a transaction volume forecast; analyze the historical transaction data to identify demographic variance factors; analyze the demographic variance factors to identify at least one demographic variance factor having a statistically significant impact on transaction time; determine a transaction time based on the at least one demographic variance factor identified; and create a full time equivalent requirement forecast based on the transaction volume forecast and the transaction time.
 16. The computer readable medium of claim 15 wherein the executable instructions, to direct the processor to analyze the historical transaction data to identify the demographic variance factors, directs the processor to compare a fluctuation in the historical transaction data caused by each of the demographic variance factors.
 17. The computer readable medium of claim 15 wherein the executable instructions, to direct the processor to analyze the historical transaction data to generate the transaction volume forecast, directs the processor to generate the transaction volume forecast based on the historical transaction data and the demographic variance factors.
 18. The computer readable medium of claim 15 wherein the transaction volume forecast comprises a transaction volume per transaction type per time interval per location forecast.
 19. The computer readable medium of claim 18 further comprising: the executable instructions configured to direct the processor to determine coefficients based on the at least one demographic variance factor and generate an enhanced transaction volume forecast based on the coefficients and the transaction volume per transaction type per time interval per location forecast.
 20. The computer readable medium of claim 15 further comprising: the executable instructions configured to direct the processor to determine a service rate per location by analyzing a standard time per transaction per location, determine an average customer arrival rate per location per time interval, calculate a service level per location based on the service rate per location and the average customer arrival rate per location per time interval, and if the service level per location meets or exceeds a target service level, calculate full time equivalent requirements to meet the target service level. 